Health care can be defined as an information industry; most of the time and money spent in procuring and delivering health care is spent creating, retrieving, or using information. Expenditures on health care information technology support, for example, have increased from about one billion dollars in 1990 to a projected $20 billion in 2000. Yet, even with these investments, it is believed that almost half of all current health care expenditures continue to be for non-patient care activities; a major share of which is for non-automated information support.
Resources having to be directed to non-patient care activities have been endemic in the health care industry since the 1960's. During the 1990's, however, with the demise of Medicare Cost Reimbursement and the rise of managed care, there has been a major shift in attitude and focus among both physicians and patients. New rules now govern the delivery of medical care and the payment for such care. Whether via preferred provider arrangements, capitation arrangements of endless variety, case management, or “best practice” enforcement, determining what care is allowed, what will be paid by whom, and making sure that the appropriate information is submitted to ensure that the process works are now consuming a major share of both time and financial resources of insurers, providers, and patients.
Health care participants, like providers and employers, regularly deal with a number of health care plans from various health insurers. These participants, however, can only obtain information from the insurance companies in limited ways, often making the acquisition of such information quite burdensome. Participants usually only have the telephone, fax, or letter available as a means of communication with the insurers.
Particularly vexing is the timely availability of information from insurers regarding financial transactions, such as eligibility, claims, and benefits, and basic patient-related information, such as medical tests and prescriptions. For example, a provider may seek information from an insurer via a submission form or telephone call to that insurer. In many cases, however, such information is sought or received after the care has been delivered and the patient has left the provider's office. This may result in the delivery of services that are not authorized or covered by the patient's insurer, or may result in other consequences that might impact the type or cost of the services provided.
Another reason for these difficulties is the recent expansion of the “payor” community. At one time, payors consisted of the government (both federal and state) and large insurance companies. Now, a complex array of self-insured plans, IDN's, IPA's, and PPO's, undertaking full or partial capitation, insurance carve-outs, and the like have radically increased the number of users of and the need for, current information regarding insureds. Most of these entities, both small and large, do spend considerable sums on information systems. Yet, because of the extent of manual processing that exists despite these systems, costs per claim remain substantial.
In addition, payors incur the wrath of their providers and patients by designing complex rules that are difficult or perceived as impossible to administer or follow. Though contrary to this perception, payors do have an interest in providing timely information to providers, patients, employers, and other participants. Still, a significant percentage of a provider's claims are rejected often because they do not comply with all of the rules. These claims require resubmission, telephone calls, and other expensive manual interventions. The dollar costs for this current processing scheme are high. In fact, an entire clearinghouse industry has been developed to provide eligibility (but not benefits) verification services to providers for a fee. Many of the requested verifications, however, cannot be performed at all by such clearinghouses, and those that are performed are often unacceptably cumbersome and, thus, too expensive.
Referral authorizations are often even more complex than claims and such authorization services are generally not available via traditional clearinghouses. Each time a provider writes a prescription, for example, it is written against a formulary specific to that patient's health care plan established by their insurer. Because there are so many formularies, drug prescriptions, too, are often rejected for payment, causing additional work for both the provider and the patient. Similarly, medical tests must be sent to laboratories contracted to support a particular plan, and are reimbursed only when matching complex medical necessity rules.
Many providers do have practice management systems that track encounters and manages billing. None of these systems, however, have the sophistication to accomplish the task of providing all of the information from all the various health insurers in such a cogent form that can be useful to the provider.
Not only providers, but patients, too, spend a majority of their time interacting with the health care system engaged in non-health care activities. This “wasted” time is virtually all related to scheduling appropriate interventions, to waiting for information or services, or to obtaining authorization, reimbursement, or other information for desired or required health care.
The internet has emerged as a major source of health care information for the public. A substantial portion of internet users use it for health care information or management. Specifically, patients search the internet for medical information and answers related to their area of concern. In fact, it is becoming common for a patient to enter a physician's office armed with printouts and long lists of questions and recommendations from web pages on the internet.
Unfortunately, even with the connectivity the internet provides, information exchange between insurers and patients is lacking. Most of the information available to patients from their insurer is on an automated basis from databases related to either general health care literature or to specific normality support groups. A critical aspect of the patient's health care program, however, is not only knowledge of the normality or support groups, but also what their insurer's health care plan provides as treatment options for that normality, eligibility information, referral authorization, claim submission and payment, testing, and medications. As discussed, these functionalities are too complicated for the current system to handle in an automated environment. Personally-referenced information linked to an individual patient's provider and health care plan is generally unavailable, because that data exists in several databases often each in a different, incompatible format, requiring human intervention to extract and process the data. The patient's current solution is, thus, an endless number of telephone calls at a high cost in dollars, time, and frustration.
A reason for such incompatibility is that each database served the individual needs of those using the data before such a time when connectivity between databases was a consideration. The consequence of having different databases of different formats is that it is not possible to provide a central repository of homogenized data readable by any variety of computers. It is this incompatibility that prevents wide spread connectivity between insurers and participants.
Transliterating and interfacing programs are known in the art. Programs that take data in one format can be translated and read by a computer of a different format. Such transliterating, however, only shifts data from a field of an incompatible format to a target field of a new format. It cannot determine whether the data of the incompatible format is being transferred to the correct target field. Normalization or remodeling of the data not only transfers the data, but also determines the meaning of the data and puts that data in the correct field.
It would, therefore, be beneficial to provide a system with which insurers may communicate with providers, patients, etc., to provide information about a particular health care plan either before, or contemporaneously with, the patient's visit to the provider, regardless the lack of compatibility of the databases. It would be further beneficial if this system of communication spanned a variety of insurers so the provider, for example, may communicate with any plan in which the patient participates. It would also be beneficial for providers to have an automated system of determining eligibility and benefits, receiving authorizations and pre-certifications, submitting claims, obtaining reimbursements, and adjudicating claim problems through the normalization of data of the incompatible databases.
In addition, there is a substantial distinction between an electronic medical record (“EMR”) and a personal health record (“PHR”), which is also commonly called an individual health record (“IHR”). The terms “PHR” and “IHR” are interchangeably used herein.
An EMR is provider-centric while a PHR is patient-centric. An EMR is not a complete health record of a patient, but is limited in scope to a specific health care provider. Notably, the electronic medical record does not contain any information from any other health care provider who does not have access or share the same specific EMR.
Electronic medical records are known. Typically, the EMR is established by hospitals or a group of physicians or less commonly by a physician. The EMR details each encounter between the patient and the provider for each episode of illness treated by the specific provider (hospital, physicians, or other care givers). Although the EMR is the commonly looked to as the medico legal record of that particular episode of illness and its management, it does not contain any information from any other provider who does not have access or share the same specific EMR.
A patient has no control over his/her EMR. For example, patients have no direct online access to their EMR and cannot make any entries in the record. Patients have no control over the access to their EMR and anyone who has access to the EMR of the specific hospital or physician group could access their health records. There is no complete global unified record of a patient in an EMR unless and until the entire healthcare is being delivered by the one provider group who is using the specific EMR for all patient encounters. The EMR system usually is used by a limited number of users (providers).
Accordingly, an illustrative embodiment of the present disclosure provides an apparatus for communicating health care data from a sender to a receiver. The apparatus comprises a first computer system, a second computer system, and a rules engine. The first computer system having health care data stored therein. The second computer system is in operable communication with, and is configured to extract the health care data from the first computer system. The rules engine normalizes the extracted health care data to a predefined format. The rules engine defines a plurality of health care data fields in the predefined format, as well as a plurality of relationships between fields of normalized data.
Further embodiments may include the first computer being a plurality of computers each having portions of the health care data stored thereon. The apparatus may also comprise a third computer system, in operable communication with, and configured to receive the normalized data from, the second computer system. The rules engine may determine whether the third computer is authorized to receive the health care data.
Another illustrative embodiment provides a method for communicating health care data from one computer system to another. The method comprises the steps of storing health care data in a first computer system; extracting health care data from the first computer system and communicating the extracted data to a second computer system; normalizing the extracted data to a predefined format in accordance with a rules engine that defines a plurality of health care data fields in the predefined format and a plurality of relationships between fields of normalized data; and communicating the normalized data to a third computer system.
Further embodiments of the illustrative method may include the first computer system comprising a plurality of computers, wherein the storing step includes storing health care data in more than one of said computers. Also, the third computer system comprises a plurality of computers. The health care data exists across a plurality of databases such that each of the plurality of databases are in operable communication with the second computer system.
Another illustrative embodiment provides a system of exchanging health care data between a sender and a receiver. The system comprises a sender computer, an intermediary computer, a rules engine and a receiver computer. The sender computer stores the health care data. The intermediary computer is in operable communication with the sender computer and is configured to extract the health care data. The extracted data is normalized to a predefined format, creating normalized data pursuant to a rules engine. The rules engine defines each field of the health care data and converts each field to a corresponding field in the predefined format. The rules engine also defines how the normalized data should relate to each other pursuant to predetermined instructions. The receiver computer is in operable communication with the intermediary computer. The receiver computer receives the normalized data subjected to the second rules engine.
Further embodiments may include the sender computer being a plurality of computers each having portions of the health care data stored thereon. The rules engine may determine whether the receiver computer is authorized to receive the health care data. When the receiver is a health care provider, the normalized data exchanged between the sender and receiver may be chosen from a group comprising eligibility/benefit display, member roster, claim submission, provider lookup, formulary lookup, diagnosis code lookup, procedure code lookup, access health plan information online, communicate with a health plan on-line, communicate with patients on-line, patient-centric view of data across several health plans, order generation and tracking, results review and release, result printing, prescription writing, medication profile for each patient, access to patient's personal health record based on patient approval, personalized medical and health care content integration, both context-specific and on demand, e-commerce integration: office, medical and health-related product awareness and buying capabilities, email, practice management system subscription, support disease management, and physician credentialing subscription. When the receiver is an employer, the non ialized data exchanged between the sender and receiver is chosen from a group comprising group eligibility, group enrollment, enrollment changes, formulary lookup, e-commerce integration, access from health plan web site or direct access via URL, personalized content integration, both context-specific and on demand, e-commerce integration and health care-related product awareness and buying capabilities.
When the receiver is a patient, the normalized data exchanged between the sender and receiver is chosen from a group comprising identification card requests, address changes, provider directory inquiries, personalized health information based on an interest profile, diagnosis information, relevant articles and patient education materials, communications from health care providers and health care plans, lab and radiology results, scheduled appointments with a health care provider, prescription refills, personal health records, eligibility/benefit information, claim information, referral and authorization information and status, provider lookup, family history, medication profile and formulary lookup.
Another illustrative embodiment of the present invention provides a system of normalizing health care data for transfer between an insurer and a participant. The system comprises an insurer system, an intermediary system, and a participant system. The insurer system is configured to maintain at least one database comprising the health care data. The intermediary system is operatively connected to the insurer system and to the database, configured to extract the health care data from the database of the insurer system, and store the health care data in a staging database as extracted data. The extracted data is normalized to a predefined format, creating normalized data pursuant to a rules engine that defines each field of the extracted data in the predefined format. The rules engine also defines how the normalized data relates to each other pursuant to predetermined instructions. The participant system is in operable communication with the intermediary system, and is configured to receive the normalized data subject to the rules engine.
Further embodiments of the illustrative system may include the at least one database being a plurality of databases, such that the intermediary system is operatively connected to the plurality of databases. In addition, the participant system may transmit a request that is sent to the intermediary system that determines which health care data is to be extracted and normalized in order to respond to the request. The participant system may also transmit the request, and the intermediary system may transmit the normalized data over the interne. The rules engine may define the relationships among the normalized data pursuant to predetermined instructions to determine a response to the request. The intermediary system may also comprise an error data system that removes extracted data identified as invalid when the extracted data is normalized. The extracted data identified as invalid is then corrected, reintroduced, and is normalized. The intermediary system may further comprise an audit database to track the activity of the intermediary system.
Another illustrative embodiment of the present invention provides a system of health care management of medical testing administration between an insurer, a medical laboratory, and at least one health care participant. The system comprises a participant computer, an insurer processing system, a rules database, and a laboratory computer. A medical test request is made at the participant computer pursuant to a first predetermined format. The insurer processing system is operatively coupled to the participant's computer, and is through which the medical request is transferred. The processing system is operatively coupled to the rules database to approve the medical test request pursuant to predetermined criteria. The laboratory computer is operatively coupled to the processing system and receives the medical test request if approved by the rules engine. Results of the medical test are transmitted from the laboratory computer to the processing system. The results are further transmitted to an insurer computer that is operatively coupled to the laboratory computer and to participant's computer.
Further embodiments of the illustrative system may include the processing system converting the results of the medical test to a second predetermined format readable by a database stored on the insurer computer. In addition, at least one health care participant may be chosen from a group comprising from a health care provider, an employer, and a patient. Furthermore, the medical test request and the results of the medical test may be transmitted through the internet.
The present invention is not merely a system for electronically storing and accessing medical records, but relates to computerized systems and methods, including software attendant thereto, for generating a personal health record (“PHR”), also described as an Individual Health Record or Electronic Health Record (hereafter “IHR” or “EHR”). In contrast to an EMR, the PHR contemplated herein is intended to include all relevant health-related information for a patient, regardless of the specific health care provider. The clinical information regarding the individual patient may be collected from diverse sources including, but not limited to information from claims through the health plans, multiple EMR's being used from different providers providing care to that patient, medication records from the pharmacy benefit managers (“PBMs”), information from labs and imaging centers, and direct input by the patient to provide a unified personal/individual health record. The PHR may contain health records of millions of patients with online access to those millions of patients.
In one embodiment, the invention provides a system and method for generating a personal/individual health record that is compiled from diverse sources, such as patient questionnaires or direct input, health plans, pharmacy benefits managers (“PBMs”), labs, imaging centers, freestanding outpatient facilities, hospitals and physicians. The data collected from the diverse sources is organized into an individual health record for a patient. The individual health record may be integrated with SNOMED codes to allow that data to be encoded under specific medical diagnostic concepts. SNOMED is a division of the College of American Pathologists (“CAP”). SNOMED Clinical Terms (“SNOMED CT”) is a scientifically-validated, clinical health care terminology and infrastructure. Health data can be captured, shared and aggregated in a consistent manner by the SNOMED CT terminology. The terminology currently contains over 350,000 hierarchically specified health care concepts, each with unique meanings and logic-based definitions. Additionally, these health care concepts have distinct relationships that support reliability and consistency for data retrieval. As used herein, the term “universal health care concept codes” means a common language that enables a consistent way of indexing, storing, retrieving and aggregating clinical data across specialties and sites of medical care. Each “universal health care concept code” is a unique identifier indicative of a node in a hierarchy of health care concepts to which other types of medical data can be mapped. The term “universal health care concept code” is intended to be synonymous with the teen “SNOMED code.”
In some embodiments, security and medical privacy could be provided such that a patient could have the ability to permit the entire individual health record to be viewed by designated persons or only permit selected parts of the record to be viewed by the authorized persons. This authorization is based on the ability of a patient to block any information relating to a protected class (e.g., mental health, reproductive system conditions in a female or STD, etc.) and/or functional area (e.g., illness/condition list, procedure list, medication profile, etc.). Any part of the record relating to that protected class and/or functional-area could be blocked and continued to be automatically blocked until a change is made by the patient.
According to another aspect, the invention provides a method for generating a personal/individual health record. The method may include the act of receiving a data element indicative of a health related parameter for a patient. The act of determining a SNOMED code corresponding to the data element may be included in the method. An entry may be inserted into a personal/individual health record associated with the patient based on the determined SNOMED code.
In some illustrative embodiments, the data element may include payor claims data. For example, the data element may be a health insurance claim code. Depending on the exigencies of a particular application, the data element may include patient questionnaires or direct input, health plans, pharmacy benefits managers (“PBMs”), labs, imaging centers, freestanding outpatient facilities, hospitals and physicians. Embodiments are also contemplated in which the data element may include an ICD code, a CPT code, a NDC code, LOINC code, or a code from a proprietary coding system, such as Lapcorps' lab and order codes.
The method may include the act of transmitting a description of the entry to a client system in some embodiments. In some cases, a first description and a second description may be associated with the entry. In such embodiments, the first description could be synonymous with the second description. For example, the first description may use medical terminology whereas the second description could use layman's terms. Preferably, the first description is transmitted if the client system is associated with a healthcare provider whereas the second description is transmitted if the client system is not associated with a health care provider.
In some illustrative embodiments, the method may include the act of determining whether the individual health record includes any entries related to the new entry. Preferably, any entries in the individual health record that are related to the entry are associated based on the determined SNOMED code.
According to another aspect, the invention provides a data processing system with a messaging facility configured to receive a data element indicative of a health related parameter for a patient. The system may include a correlation module configured to determine a SNOMED code corresponding to the data element. A PHR population engine may be operably associated with the correlation module, such that the PHR population engine is configured to insert health related data associated with the SNOMED code into a personal/individual health record associated with the patient.
In some embodiments, the system may include an access management module configured to communicate with a client system. In some cases, the access management module could be configured to transmit a description of the health related data to the client system. For example, the PHR population engine may associate more than one synonymous description with the health related data. Embodiments are contemplated in which some of the descriptions use medical terminology and others use layman's terms.
The system may include a filtering module in some embodiments. Typically, the filtering module may be configured to determine whether the client system is associated with a healthcare provider. The description transmitted to the client system may differ depending on whether the client system is associated with a healthcare provider. In some embodiments, the filtering module may be configured to change the description of the health related data based on a description of a SNOMED code up a SNOMED hierarchy to adjust the resolution of data.
In some embodiments, the system may include a PHR database configured to store a plurality of individual health records. The system may also include a data analysis module configured to identify patterns or relationships among the plurality of individual health records in the PHR database based on related SNOMED codes. For example, the data analysis module may be configured to measure effectiveness of healthcare treatment based on outcomes associated with the plurality of individual health records having related SNOMED codes. In some cases, the data analysis module may be configured to perform population studies based on SNOMED codes in the plurality of individual health records.
Embodiments are also contemplated in which the data analysis module may be configured to analyze a health care provider's quality of care and cost. For example, the data analysis module may profile health care providers based on patient outcomes associated with the health care providers. Likewise, the health care providers could be profiled in terms of costs, such as the cost charged by health care providers for various procedures. Health care providers could thus be ranked based on quality of care and cost. This information could allow various payors, such as insurance companies or governmental entities, to establish a list of preferred health care providers based on a formula that includes objective measures for quality of care and cost, as well as possibly other factors.
According to a further aspect, the invention provides a method of generating a personal/individual health record. The method may include the act of receiving a claims data element indicative of a health insurance claim associated with a patient. The SNOMED code corresponding to the claims data element may be determined. The method may also include inserting the SNOMED code into a personal/individual health record associated with the patient.
In some embodiments, the method may include the act of receiving a questionnaire data element indicative of an answer to a questionnaire by the patient. A SNOMED code corresponding to the questionnaire data element may be determined and inserted into the individual health record associated with the patient. Embodiments are also contemplated in which the method includes the act of receiving a clinical data element indicative of clinical data associated with the patient. In such embodiments, a SNOMED code corresponding to the clinical data element may be determined and inserted into the individual health record associated with the patient.
According to another aspect, the invention provides a method for generating a personal/individual health record. The method may include the act of receiving a data element indicative of a health related parameter for a patient. A health related concept that corresponds to the data element may be identified, such that the health related concept is selected from a hierarchical arrangement of health related concepts. A new entry may be inserting into the individual health care record that is representative of the identified health related concept. Also, the new entry may be associated with entries in the individual health record that have a hierarchical relationship to the new entry.
In some embodiments, the hierarchical arrangement includes nodes representative of medical diagnoses or medical procedures. For example, the hierarchical arrangement may include at least 300,000 nodes, such as a plurality of SNOMED Clinical Terms.
According to a further aspect, the invention provides a computer-readable medium having a data structure stored thereon. The data structure may include a diagnosis data field for storing a plurality of diagnosis data elements representative of medical diagnoses associated with a patient. For example, at least one diagnosis data element may be derived from a payor diagnosis code based on a SNOMED code. A procedure data field for storing a plurality of procedure data elements representative of medical procedures associated with the patient may also be included in the data structure. Preferably, at least one procedure data element is derived from a payor procedure code based on a SNOMED code. In some cases, the data element may be manually entered.
In some embodiments, a diagnosis data element may be derived from an ICD code. Embodiments are also contemplated in which a procedure data element may be derived from a CPT code. Other embodiments are contemplated in which other health-related information could be derived from other types of codes, such as LOINC codes or proprietary codes, such as Lapcorbs' lab and order codes.
Depending on the particular application, the data structure may include a medication data field for storing a plurality of medication data elements representative of medications associated with the patient. For example, a medication data element may be derived from a health insurance medication code based on a SNOMED code. In some cases, a medication data element may be derived from a NDC code. In some embodiments, the procedure data element may be derived from a questionnaire answered by the patient based on a SNOMED code associated with an answer to the questionnaire.
A still further aspect of the invention is achieved by a computer-usable medium having computer readable instructions stored thereon for execution by a processor to perform a method. In some cases, the method includes the act of receiving a claims data element indicative of a health insurance claim associated with a patient. A SNOMED code corresponding to the claims data element may be determined and inserted into a personal/individual health record associated with the patient. The method may include the act of receiving a questionnaire data element indicative of an answer to a questionnaire by the patient. The SNOMED code corresponding to the questionnaire data element may be determined and inserted into the individual health record associated with the patient. The method may include the act of receiving a clinical data element indicative of clinical data associated with the patient. The SNOMED code corresponding to the clinical data element may be determined and inserted into the individual health record associated with the patient.
According to another aspect, the invention provides a method for selectively restricting access to a personal/individual health record. The method may include associating an access list for each user capable of accessing a personal/individual health record associated with a patient, such that the access list categorizes the individual health record into a restricted set of data elements and an accessible set of data elements. A request may be received from a user for a data element in the individual health record. The method may include the act of determining whether the data element is in the restricted set of data elements by reviewing an access list associated with the user. If the data element is in the restricted set of data elements, access to the data element will be denied. However, if the data element is in the accessible set of data elements, the user will be allowed to access to the data element. In some embodiments, a predetermined list of possible restricted areas may be presented to a patient. The access list may be created responsive to selections by the patient.
According to a further aspect, the invention provides a method for generating a individual health record, in which the desired information from each source is pre-selected so as to collect information which is important and necessary for the continuing care of a patient and thus avoid massive accumulation of data in the patient's individual health record, which has none or little relevance to continuing care. This allows the user not to spend excessive amounts of time scrolling through lots of data to find actionable information. For example, a massive amount of information is typically collected in an EMR following an inpatient admission, such as extensive nursing reports, voluminous lab results, information regarding the scheduling of tests and procedures during the hospitalization. In some cases, the information which is imported in the PHR may be less than ten percent of the EMR and include only pre-selected types of data, such as the admission history and physical exam, discharge summary and discharge plans, and surgical report and pre-selected test results such as MRI, CT-Scans, and angiography results.
A further aspect of the invention is achieved by a method for generating a personal/individual health record. The method may include the act of receiving payor claims data associated with a patient. Encounter data indicative of an encounter between the patient and a health care provider may be derived from the payor claims data. A new entry may be inserted into a personal/individual health record associated with the patient based on the encounter data. In some embodiments, the deriving step may include deriving a primary care physician encounter history, an outpatient encounter history and a hospital admissions history from the payor claims data.
According to another aspect, the invention provides a method of filtering data in a personal/individual health record. The method may include receiving a request from a health care provider for a personal/individual health record associated with a patient. A specialty associated with the health care provider may be identified. The data elements in the individual health record that relate to the specialty of the health care provider may be determined. In response to the request, the health care provider may be presented with any data elements in the individual health record that were determined to relate to the specialty.
Additional features and advantages of the system will become apparent to those skilled in the art upon consideration of the following detailed descriptions exemplifying the best mode of carrying out the system as presently perceived.
Corresponding reference characters indicate corresponding parts throughout the several views. The exemplification set out herein illustrates an embodiment of the invention, and such exemplification is not to be construed as limiting the scope of the invention in any manner.